Skip to main content

Example setups

Five worked recipes, each built entirely in the setup app and wired into Crestron Home programming. They are ordered from the everyday to the more specialised, and between them they exercise most of the driver: HTTP out with feedback, a macro, an auto-off timer, a raw socket transport, and an inbound event driving a scene.

Every recipe follows the same shape: what you're building → set up the control → the request(s) → wire it into programming. Full detail for each field is on Buttons that call out and Webhooks in.

1. A Shelly relay, with honest feedback​

What you're building: a two-state button that switches a Shelly relay on and off, and shows the state the relay actually reports — not just what you asked for.

Set up the control (Buttons tab → Add):

  • Name it Pump.
  • Two states: Off (icon icPowerDisabled) and On (icon icPowerRegular).

The requests — one HTTP request on each state's On entering list:

StateSend asMethodURL
OffHTTP requestGEThttp://192.168.1.50/relay/0?turn=off
OnHTTP requestGEThttp://192.168.1.50/relay/0?turn=on

On the On request, turn on Read to confirm the result:

  • Read: JSON path
  • Path: result.relay.0.ison
  • Map true → On, false → Off.

Now if the relay was toggled elsewhere, or refused the command, the tile corrects itself to the truth.

Wire it in: bind a scene to the "Pump — On" event, or drive the pump from a schedule with the SetElementState action.

2. A gate-and-light macro​

What you're building: one button that unlocks a gate, waits two seconds, then turns on a light — a sequence, from a single press.

Set up the control: a one-state momentary button named Arrive, icon icGate.

The requests — a list of two requests on the state's On entering, each with a delay:

  1. POST http://192.168.1.60/unlock — Delay before sending: 0
  2. GET http://192.168.1.61/light/on — Delay before sending: 2000

The delay on the second request is what sequences the macro. Add more steps the same way.

Mix transports in one macro

The steps in a list do not have to share a transport. A macro can fire an HTTP call, then a TCP command, then a UDP datagram — whatever each device speaks.

Wire it in: nothing extra needed — the press runs the macro. Or fire the whole sequence from a scene with PressElement.

3. A cooker switch that turns itself off​

What you're building: a switch that can be turned on, but never left on — it reverts to off after a set time, with a countdown on the tile. This is the classic "cooker isolator" safety pattern.

Set up the control (Buttons tab → Add):

  • Name it Cooker.
  • Two states: Off and On.
  • Turn on This element's state also drives the room tile so the countdown shows on the tile.

The auto-off — on the On state:

  • Enable Leave this state automatically after a timeout.
  • After (seconds): 5400 (90 minutes).
  • Go to: Off.

Add whatever HTTP/socket requests actually switch the cooker circuit to each state, as in recipe 1. When the timer fires, the Off state is entered for real — its event and its requests run, exactly as if someone had pressed it.

On the tile: while it is on, the status line counts down — 1h 30m remaining, … 2 mins remaining, 45s remaining — then returns to Off when it reverts. Turning it off by hand (or from a program) before the deadline cancels the countdown; nothing fires late.

Reboots drop the timer

If the processor reboots mid-countdown, the cooker comes back off (or in its forced state) with no timer armed. Don't rely on the auto-off surviving a power cut. See Limitations and notes.

4. A projector over raw TCP​

What you're building: a two-state button that powers a projector on and off over its raw TCP command port — a device with no web API at all.

Set up the control: a two-state button named Projector, states Off and On.

The requests — a TCP request on each state. Say the projector listens on port 4352 and its power commands are PWR OFF and PWR ON, each terminated by a carriage return:

StateSend asHostPortPayload
OffTCP (connect + send)192.168.1.704352PWR OFF\r
OnTCP (connect + send)192.168.1.704352PWR ON\r

The \r in the payload is turned into a real carriage return before sending — see payloads, terminators and raw bytes. For a device that frames commands in STX/ETX, you would type \x02PWR ON\x03.

To confirm the projector actually changed power, turn on Wait for a reply and use Read to map its response onto the state, the same way recipe 1 reads the Shelly's JSON.

A UDP variant

If the device takes a single UDP command instead, choose UDP datagram, give the same host, port and payload, and it is sent fire-and-forget — no reply, no confirmation.

Wire it in: bind "Projector — On" into your "Cinema" scene, and drive it from a schedule with SetElementState.

5. A doorbell that fires a Crestron scene​

What you're building: a doorbell (or any device that can send one HTTP request) that triggers a Crestron Home scene, with the room tile doubling as the acknowledge button.

Get the webhook URL (Webhooks tab): copy the fire event example and set the event name — say doorbell. It looks like:

http://<processor-ip>/cws/<room>_CHUIDYNAMIC/hook?token=<token>&event=doorbell

Paste that into whatever the doorbell can call (a Home Assistant automation, an IFTTT applet, the doorbell's own webhook field).

Wire it in: in Crestron Home programming, bind a rule to the "Webhook received" event and act when its name is doorbell — that runs your "Someone's at the door" scene. (There's no per-name event to create: one event carries every webhook's name.) A single GET from the doorbell now runs the scene, with no control involved. See Webhooks in and Events and actions in programming for the full inbound vocabulary.

Make the tile the acknowledge button (optional): on the Tile tab, set Press behaviour to Acts as a button (no page) and point Presses at an Acknowledged control. Now the whole room tile is the "I've got it" button, and its Tile pressed event can silence a chime or update a status elsewhere.